| Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド
リリース7.0 E05169-01 |
|
 前へ |
 次へ |
RETURNサービスを指定してレプリケーション・スキームを設定すると、レプリケート・データがマスターおよびサブスクライバの両方のデータ・ストアで一貫していることをより高いレベルの信頼性を持って保証できます（「レプリケーション・エージェントによって更新をデータ・ストア間でコピーする方法」を参照）。この項では、RETURN RECEIPTおよびRETURN TWOSAFEサービスの設定方法および管理方法について説明します。
この項の内容は次のとおりです。
データがマスターおよびサブスクライバの両方のデータ・ストアで一貫していることをより高いレベルの信頼性を持って保証するには、RETURNサービスを選択します。非同期モード（デフォルト）、RETURN RECEIPTモード、RETURN TWOSAFEモードのいずれを使用するかは、必要とする信頼性の程度および許容できるパフォーマンスのトレードオフによって決まります。これらのトレードオフの詳細は、「パフォーマンスとリカバリのトレードオフ」を参照してください。2つのRETURNサービス間のパフォーマンスとリカバリのトレードオフに加えて、次のことも検討する必要があります。
| 注意: | アプリケーションでRETURN RECEIPTまたはRETURN TWOSAFEのいずれかに設定された表を更新する場合、トランザクションはRETURN RECEIPTまたはRETURN TWOSAFEとして分類されます。RETURN RECEIPTまたはRETURN TWOSAFEとして分類されたトランザクションは、終了前にレプリケーション・スキームが変更された場合でも、そのままの状態が維持されます。 |
次の各項では、次に示すRETURNサービス属性について説明します。
TimesTenでは、アプリケーションをレプリケーション・メカニズムと疎結合または同期するためにオプションのRETURN RECEIPTサービスが提供されています（「RETURN RECEIPTレプリケーション」を参照）。
RETURN RECEIPT属性を指定して、ELEMENT記述のSUBSCRIBER句に示されたサブスクライバに対してRETURN RECEIPTサービスを有効にできます。RETURN RECEIPTが有効になっている場合、アプリケーションは、マスター・データ・ストアの要素に対するトランザクションをコミットすると、サブスクライバがトランザクション更新の受信を確認するまでブロックされたままになります。マスターが複数のサブスクライバに要素をレプリケートしている場合、すべてのサブスクライバがトランザクション更新の受信を確認するまで、アプリケーションはブロックされたままになります。
RETURN RECEIPTを使用するレプリケーション・スキームの例は、例3.16を参照してください。
マスター・データ・ストア（masterds）のrepl.tab表に対してコミットしたすべてのトランザクションがサブスクライバ（subscriberds）で受信されたことを確認する場合、ELEMENT記述（e）は次のようになります。
ELEMENT e TABLE repl.tab
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
RETURN RECEIPT
設定可能なタイムアウト時間内にいずれかのサブスクライバでトランザクションの受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。
ttRepXactStatusプロシージャを使用してRETURN RECEIPTトランザクションのステータスを確認できます。詳細は、「RETURNサービス・トランザクションのステータスの確認」を参照してください。
また、タイムアウトが特定の回数発生した後、RETURN RECEIPTサービスを無効にするようにレプリケーション・エージェントを設定できます。詳細は、「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照してください。
| 注意: | RETURN SERVICES OFF WHEN REPLICATION STOPPED設定はRETURN RECEIPTサービスのデフォルト設定のため、レプリケーションが停止するとRETURN RECEIPTサービスは無効になります。詳細は、「RETURN SERVICES { ON | OFF } WHEN REPLICATION STOPPED」を参照してください。 |
RETURN RECEIPTは、すべてのトランザクションに対して受信の通知を有効にします。BY REQUESTオプションを指定してRETURN RECEIPTを使用すると、アプリケーションで識別される特定のトランザクションに対してのみ受信通知を有効にできます。
サブスクライバにRETURN RECEIPT BY REQUESTを指定する場合は、ttRepSyncSetプロシージャを使用して、トランザクションに対してRETURN RECEIPTサービスを有効にする必要があります。RETURN RECEIPTサービスを有効にするコールは、トランザクションの一部である必要があります（AutoCommitは無効である必要があります）。
マスター・データ・ストア（masterds）のrepl.tab表に対してコミットした特定のトランザクションがサブスクライバ（subscriberds）で受信されたことの確認を有効にする場合、ELEMENT記述（e）は次のようになります。
ELEMENT e TABLE repl.tab
MASTER masterds ON "system1"
SUBSCRIBER subscriberds ON "system2"
RETURN RECEIPT BY REQUEST
受信通知が必要なトランザクションをコミットする前に、SQLExecDirect関数内でttRepSyncSetをコールしてRETURNサービスをリクエストし、タイムアウト時間を45秒に設定します。
rc = SQLExecDirect( hstmt, (SQLCHAR *)
"CALL ttRepSyncSet(0x01, 45, NULL)", SQL_NTS )
設定可能なタイムアウト時間内にいずれかのサブスクライバでトランザクション更新の受信を確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。
ttRepSyncGetを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。次に例を示します。
Command> CALL ttRepSyncGet();
< 01, 45, 1>
1 row found.
RETURN RECEIPT BY REQUESTを使用するレプリケーション・スキームの別の例は、例3.21を参照してください。
TimesTenでは、アプリケーションをレプリケーション・メカニズムと完全に同期させるRETURN TWOSAFEサービスが提供されています（「RETURN TWOSAFEレプリケーション」を参照）。RETURN TWOSAFEサービスの場合、各レプリケーション・トランザクションは、マスター・データ・ストアでコミットされる前にサブスクライバ・データ・ストアでコミットされます。サブスクライバでトランザクションがコミットされたかどうかをレプリケーションで確認できなかった場合は、エラー通知が返されます。エラー受信後、アプリケーションで、障害のタイプに応じて、固有のアクションまたは事前に定義されているアクションのいずれかを実行できます。
| 注意: | RETURN TWOSAFEは、2つのデータ・ストアが常に同期されている必要があるレプリケーション・スキームでの使用を前提としています。一方のデータ・ストアのロールはアクティブ状態です。もう一方のデータ・ストアのロールはスタンバイ状態ですが、いつでもアクティブ状態になることができる準備ができている必要があります。RETURN TWOSAFEは、アクティブ・スタンバイ・ペア、または2つのみのデータ・ストアによる双方向レプリケーション・スキームで使用できます。 |
サブスクライバに対してRETURN TWOSAFEサービスを有効にするには、CREATE REPLICATIONまたはALTER REPLICATION文のSUBSCRIBER句にRETURN TWOSAFE属性を指定します。
マスター・データ・ストア（datastoreA）でコミットされたすべてのトランザクションがサブスクライバ（datastoreB）でもコミットされたことを確認する場合、ELEMENT記述（a）は次のようになります。
ELEMENT a DATASTORE
MASTER datastoreA ON "system1"
SUBSCRIBER datastoreB ON "system2"
RETURN TWOSAFE
RETURN TWOSAFEが指定された双方向のホット・スタンバイ構成でdatastoreAおよびdatastoreBの両方を指定するCREATE REPLICATION文全体は、次のようになります。
CREATE REPLICATION repl.hotstandby
ELEMENT a DATASTORE
MASTER datastoreA ON "system1"
SUBSCRIBER datastoreB ON "system2"
RETURN TWOSAFE
ELEMENT b DATASTORE
MASTER datastoreB ON "system2"
SUBSCRIBER datastoreA ON "system1"
RETURN TWOSAFE;
レプリケーションがRETURN TWOSAFEで構成されている場合は、AutoCommit接続属性を無効にする必要があります。
アプリケーションは、マスター・データ・ストアでトランザクションをコミットすると、トランザクションが正常にコミットされたことがサブスクライバで確認されるまでブロックされたままになります。両方のデータ・ストアで同じ更新または削除を開始すると、コミットがデッドロックする可能性があります。これは、処理を停止することでのみ解決できます。
設定可能なタイムアウト時間内にサブスクライバでトランザクション更新のコミットを確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。
RETURN TWOSAFEサービスを使用すると、マスター・レプリケーション・エージェントによるタイムアウト・エラーへの対処方法を指定することができます。これは、CREATE REPLICATION文のSTORE句にLOCAL COMMIT ACTION属性を設定するか、またはプログラムでttRepSyncSetプロシージャのlocalActionパラメータを使用して実行できます。RETURN TWOSAFEトランザクションのレプリケーション中にタイムアウトを受信した場合に、実行可能なアクションは次のとおりです。
また、タイムアウトが特定の回数発生した後、RETURN TWOSAFEサービスを無効にするようにレプリケーション・エージェントを設定できます。詳細は、「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照してください。
コールしてサブスクライバ上でのトランザクションの適用に関するエラー（主キー検索障害など）が返された場合、アプリケーションでトランザクションのロールバックを選択できます。
コールして前述のエラー以外のエラーが返された場合は、「RETURNサービス・トランザクションのステータスの確認」で説明されているttRepXactStatusプロシージャを使用して、トランザクションのステータスを確認できます。エラーに応じて、アプリケーションで次のいずれかの処理を選択できます。
マスター・データ・ストアで障害が発生した場合、マスターはキャッチアップ機能（「障害が発生したマスター・データ・ストアの自動キャッチアップ」を参照）によってサブスクライバから自動的にリストアされます。
| 注意: | RETURN SERVICES ON WHEN REPLICATION STOPPED設定はRETURN TWOSAFEサービスのデフォルト設定のため、レプリケーションが停止した場合でもRETURN TWOSAFEは継続してアプリケーションをブロックします。詳細は、「RETURN SERVICES { ON | OFF } WHEN REPLICATION STOPPED」を参照してください。 |
RETURN TWOSAFEは、すべてのトランザクションに対してサブスクライバでのコミットの通知を有効にします。BY REQUESTオプションを指定してRETURN TWOSAFEを使用すると、アプリケーションで識別される特定のトランザクションについてのみサブスクライバ・コミットの通知を有効にできます。
サブスクライバにRETURN TWOSAFE BY REQUESTを指定する場合は、ttRepSyncSetプロシージャを使用して、トランザクションに対してRETURN TWOSAFEサービスを有効にする必要があります。RETURN TWOSAFEサービスを有効にするコールは、トランザクションの一部である必要があります（autocommitは無効である必要があります）。
マスター・データ・ストア（datastoreA）でコミットされた特定のトランザクションがサブスクライバ（datastoreB）でもコミットされたことの確認を有効にする場合、ELEMENT記述（a）は次のようになります。
ELEMENT a DATASTORE
MASTER datastoreA ON "system1"
SUBSCRIBER datastoreB ON "system2"
RETURN TWOSAFE BY REQUEST;
サブスクライバでのコミットの確認が必要なトランザクションのコミットをコールする前に、SQLExecDirect関数内でttRepSyncSetをコールしてRETURNサービスをリクエストします（タイムアウト時間を45秒、タイムアウト・エラー発生時の動作をNO ACTIONに指定）。
rc = SQLExecDirect( hstmt, (SQLCHAR *)
"CALL ttRepSyncSet(0x01, 45, 1)", SQL_NTS )
この例では、タイムアウト時間内にサブスクライバでトランザクションのコミットを確認できない場合、アプリケーションは、コミット・リクエストに対するtt_ErrRepReturnFailed (8170)警告を受信します。その後、アプリケーションは、「RETURN TWOSAFE」で説明されている方法と同じ方法でタイムアウトを処理することを選択できます。
RETURNサービス・タイムアウト時間の詳細は、「RETURNサービス・タイムアウト時間の設定」を参照してください。
ttRepSyncGetを使用して、RETURNサービスが有効になっているかどうかを確認し、タイムアウト値を取得できます。次に例を示します。
Command> CALL ttRepSyncGet();
< 01, 45, 1>
1 row found.
NO RETURN属性を使用して、RETURN RECEIPTサービスまたはRETURN TWOSAFEサービスのいずれか（有効にされているサービスに応じて）を明示的に無効にできます。デフォルト設定はNO RETURNです。通常、この属性はALTER REPLICATION文で設定します。設定例は、例6.14を参照してください。
レプリケーション・スキームが「RETURNサービスの使用」で説明されているいずれかのRETURNサービスで設定されていると、指定したタイムアウト時間内にいずれかのサブスクライバでマスターに確認応答を送信できなかった場合にタイムアウトが発生します。
デフォルトのRETURNサービス・タイムアウト時間は10秒です。CREATE REPLICATIONまたはALTER REPLICATION文のSTORE句にRETURN WAIT TIME属性を指定するか、または新しいreturnWaitパラメータを指定したttRepSyncSetプロシージャをプログラムでコールして、異なるRETURNサービス・タイムアウト時間を指定することもできます。RETURN WAIT TIMEが0（ゼロ）の場合は「タイムアウトなし」を示します。
RETURNサービスは、レプリケーション障害が発生した場合、またはレプリケーションに時間がかかりすぎて、レプリケートされる前にRETURNサービス･トランザクションがタイムアウトした場合にタイムアウトします。ただし、レプリケーション障害が同時に発生しないかぎり、サブスクライバからRETURNサービスの確認を取得することに失敗しても、トランザクションがレプリケートされていないこと、または将来レプリケートされないことを意味しない場合もあります。
他のSTORE属性を設定して、タイムアウトが過剰に発生する場合にRETURNサービス・ブロッキングを自動的に無効にし、状況が改善されるとRETURNサービス・ブロッキングを再度有効にするポリシーを設定できます。詳細は、「RETURNサービス・タイムアウト・エラーおよびレプリケーションの状態変化の管理」を参照してください。
| 注意: | タイムアウト時間は、設定後、再設定するか、またはアプリケーション・セッションが終了するまで、後続のすべてのRETURNサービス・トランザクションに適用されます。タイムアウト設定は、すべてのサブスクライバのすべてのRETURNサービスに適用されます。 |
ホット・スタンバイ・レプリケーション・スキームで、双方向にレプリケートされるデータ・ストアdatastoreAおよびdatastoreBの両方のタイムアウト時間を30秒に設定する場合、CREATE REPLICATION文は次のようになります。
CREATE REPLICATION repl.hotstandby
ELEMENT a DATASTORE
MASTER datastoreA ON "system1"
SUBSCRIBER datastoreB ON "system2"
RETURN TWOSAFE
ELEMENT b DATASTORE
MASTER datastoreB ON "system2"
SUBSCRIBER datastoreA ON "system1"
RETURN TWOSAFE
STORE datastoreA RETURN WAIT TIME 30
STORE datastoreB RETURN WAIT TIME 30;
ttRepSyncSetプロシージャを使用してタイムアウト時間を45秒に再設定するには、SQLExecDirect関数内でttRepSyncSetをコールします。requestReturnおよびlocalAction値を再設定しないようにするには、NULLを指定します。
rc = SQLExecDirect( hstmt, (SQLCHAR *)
"CALL ttRepSyncSet(NULL, 45, NULL)", SQL_NTS )
接続ハンドルで最後に実行されたRETURN RECEIPTトランザクションまたはRETURN TWOSAFEトランザクションのステータスは、ttRepXactTokenGetおよびttRepXactStatusプロシージャをコールして確認できます。
まず、ttRepXactTokenGetをコールして、最後のRETURNサービス・トランザクションに固有のトークンを取得します。RETURN RECEIPTを使用している場合は、マスター・データ・ストアで最後コミットされたRETURN RECEIPTトランザクションがトークンによって識別されます。RETURN TWOSAFEを使用している場合は、サブスクライバでのコミットが成功した場合に、マスターのレプリケーション・エージェントによってコミットされる、マスター上の最後のRETURN TWOSAFEトランザクションがトークンによって識別されます。ただし、タイムアウトなどのエラーが発生した場合、トークンによって識別されたRETURN TWOSAFEトランザクションはマスターのレプリケーション・エージェントによってはコミットされません。
次に、ttRepXactTokenGetによって返されたトークンをttRepXactStatusプロシージャに渡して、RETURNサービスのステータスを取得します。ttRepXactStatusプロシージャの出力は、レプリケート・データを受信するように設定されているサブスクライバ、および各サブスクライバに対してトランザクションの現在のステータス（未送信、受信済、コミット済）をレポートします。サブスクライバ・レプリケーション・エージェントがサブスクライバ・データ・ストアへのトランザクションの適用時に問題を検出した場合、ttRepXactStatusプロシージャにはエラー文字列も含まれます。RETURN TWOSAFEの使用時にタイムアウトなどのエラーを受信した場合は、無条件にコミットするか、コミットを再試行するかを決定できます（「RETURN TWOSAFE」を参照）。
| 注意: | ttRepXactTokenGetで取得したトークンを使用せずにttRepXactStatusをコールすると、接続上でRETURN RECEIPTまたはRETURN TWOSAFEレプリケーション・サービスによって最後にコミットされたトランザクションの状態が返されます。 |
ttRepXactStatusプロシージャは、各サブスクライバのRETURNサービスのステータスを、次のように書式設定された行セットとして返します。
subscriberName, status, error
たとえば、GetRSXactStatus関数でttRepXactTokenGetおよびttRepXactStatusを使用すると、レプリケート・システムの各サブスクライバのステータスをレポートできます。
SQLRETURN GetRSXactStatus (HDBC hdbc)
{
SQLRETURN rc = SQL_SUCCESS;
HSTMT hstmt = SQL_NULL_HSTMT;
char xactId [4001] = "";
char subscriber [62] = "";
char state [3] = "";
/* get the last RS xact id executed on this connection */
SQLAllocStmt (hdbc, &hstmt);
SQLExecDirect (hstmt, "CALL ttRepXactTokenGet ('R2')", SQL_NTS);
/* bind the xact id result as a null terminated hex string */
SQLBindCol (hstmt, 1, SQL_C_CHAR, (SQLPOINTER) xactId,
sizeof (xactId), NULL);
/* fetch the first and only row */
rc = SQLFetch (hstmt);
/* close the cursor */
SQLFreeStmt (hstmt, SQL_CLOSE);
if (rc != SQL_ERROR && rc != SQL_NO_DATA_FOUND)
{
/* display the xact id */
printf ("\nRS Xact ID: 0x%s\n\n", xactId);
/* get the status of this xact id for every subscriber */
SQLBindParameter (hstmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR,
SQL_VARBINARY, 0, 0,
(SQLPOINTER) xactId, strlen (xactId), NULL);
/* execute */
SQLExecDirect (hstmt, "CALL ttRepXactStatus (?)", SQL_NTS);
/* bind the result columns */
SQLBindCol (hstmt, 1, SQL_C_CHAR, (SQLPOINTER) subscriber,
sizeof (subscriber), NULL);
SQLBindCol (hstmt, 2, SQL_C_CHAR, (SQLPOINTER) state,
sizeof (state), NULL);
/* fetch the first row */
rc = SQLFetch (hstmt);
while (rc != SQL_ERROR && rc != SQL_NO_DATA_FOUND)
{
/* report the status of this subscriber */
printf ("\n\nSubscriber: %s", subscriber);
printf ("\nState: %s", state);
/* are there more rows to fetch? */
rc = SQLFetch (hstmt);
}
}
/* close the statement */
SQLFreeStmt (hstmt, SQL_DROP);
return rc;
}
サブスクライバ障害が発生した場合、ユーザーまたはマスター・レプリケーション・エージェントはレプリケーション状態をStopに再設定できます。また、サブスクライバが、RETURNサービスを使用しているトランザクションを確認できず、マスターに対してタイムアウトする場合もあります（「RETURN RECEIPTレプリケーション」および「RETURN TWOSAFEレプリケーション」を参照）。タイムアウト時間内にいずれかのサブスクライバがトランザクション更新を確認できない場合、アプリケーションは、コミット・リクエストに対するerrRepReturnFailed警告を受信ます。
デフォルトのRETURNサービス・タイムアウト時間は10秒です。CREATE REPLICATION文またはALTER TABLE文のSTORE句にRETURN WAIT TIME属性を指定するか、または新しいreturnWaitパラメータを指定したttRepSyncSetプロシージャをプログラムでコールして、異なるRETURNサービス・タイムアウト時間を指定することもできます。
RETURNサービスは、レプリケーション障害が発生した場合、またはレプリケーションに時間がかかりすぎて、レプリケートされる前にRETURNサービス･トランザクションがタイムアウトした場合にタイムアウトまたは失敗します。ただし、レプリケーション障害が同時に発生しないかぎり、サブスクライバからRETURNサービスの確認を取得することに失敗しても、トランザクションがレプリケートされていないこと、または将来レプリケートされないことを意味しない場合もあります。
この項では、RETURNサービス・トランザクションでのタイムアウトの検出方法および応答方法について説明します。主な内容は次のとおりです。
レプリケーションが停止した場合、またはレプリケート・システムのパフォーマンスにRETURNサービス･タイムアウト障害が悪影響を及ぼし始めた場合は、なんらかの方法で対処する必要があります。RETURNサービス･タイムアウトの許容しきい値は、特定のアプリケーションのタイムアウトの履歴頻度およびパフォーマンス/可用性の関係によって異なります。問題に対処する場合、これらの両方の要素について考慮する必要があります。
RETURN RECEIPTサービスを使用している場合の手動による対処方法としては、ALTER REPLICATIONを使用してレプリケーション・スキームを変更し、特定のサブスクライバのRETURN RECEIPTブロッキングを無効にした後で、可能な場合はttDurableCommitプロシージャをコールして、サブスクライバで受信されたかどうかを確認できなくなったマスターのトランザクションを永続的にコミットする方法があります。RETURN RECEIPTブロッキングを無効にすると決めた場合、これを再度有効にするという判断は、RETURN RECEIPTトランザクションがタイムアウトしないと確信できるレベルに基づいて行います。
手動でRETURNサービス･タイムアウト障害に対処するかわりに、RETURNサービス障害およびリカバリ・ポリシーをレプリケーション・スキームに設定して対処することもできます。これらのポリシーは、レプリケーション状態の変化の検出およびRETURNサービス･タイムアウトの追跡を行い、事前に設定したなんらかの方法で自動的に対処するようにレプリケーション・エージェントに直接指示します。
RETURN RECEIPTまたはRETURN TWOSAFEサービスを使用する場合は、CREATE REPLICATIONまたはALTER REPLICATION文の次の属性によって障害/リカバリ・ポリシーを設定します。
これらの属性によって設定したポリシーは、データ・ストアの存続期間中、または変更されるまで適用されます。ただし、これらのポリシーが施行されるには、レプリケーション・エージェントが稼働している必要があります。
レプリケーションが停止した場合は、RETURN SERVICES { ON | OFF } WHEN REPLICATION STOPPED属性によって、RETURN RECEIPTまたはRETURN TWOSAFEサービスを継続して有効にするか、無効にするかが決定されます。このコンテキストでの停止は、（ttAdmin -repStop masterなどによって）マスター・レプリケーション・エージェントが停止されたこと、または（ttRepAdmin -state stop subscriberなどによって）サブスクライバ・データ・ストアのレプリケーション状態がマスター・データ・ストアに対してStopまたはPauseに設定されたことを意味しています。指定したFAILTHRESHOLD値を超えている障害が発生したサブスクライバは、Failed状態に設定されますが、最終的にはマスター・レプリケーション・エージェントによってStop状態に設定されます。
| 注意: | サブスクライバは、RETURN WAIT TIMEで指定されたタイムアウト時間を超えるとその期間中は使用できなくなりますが、マスター・レプリケーション・エージェントでは継続してStart状態であるとみなされます。タイムアウトに関連する障害ポリシーは、DISABLE RETURN属性によって設定されます。 |
RETURN SERVICES OFF WHEN REPLICATION STOPPEDは、レプリケーションが停止すると、RETURNサービスを無効にします。これは、RETURN RECEIPTサービス使用時のデフォルト設定です。RETURN SERVICES ON WHEN REPLICATION STOPPEDは、レプリケーションが停止した場合でもRETURNサービスを継続して有効にできます。これは、RETURN TWOSAFEサービス使用時のデフォルト設定です。
masterdsデータ・ストアからsubscriber1データ・ストアに更新をレプリケートするように、CREATE REPLICATION文を設定しています。このCREATE REPLICATION文では、RETURN RECEIPTおよびRETURN SERVICES ON WHEN REPLICATION STOPPEDの使用が指定されています。
CREATE REPLICATION repl.myscheme
ELEMENT e TABLE repl.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1 ON "server2"
RETURN RECEIPT
STORE masterds ON "server1"
RETURN SERVICES ON WHEN REPLICATION STOPPED;
アプリケーションでマスターへの更新をコミットする場合は、ttRepAdminを使用してsubscriber1をStop状態に設定します。
ttRepAdmin -dsn masterds -receiver -name subscriber1 -state stop
アプリケーションは、レプリケーション状態がStartに再設定され、subscriber1からRETURN RECEIPT確認応答を受信するまでこの確認応答を継続して待機します。
ttRepAdmin -dsn masterds -receiver -name subscriber1 -state start
DISABLE RETURN値を設定すると、データ・ストアは、RETURN WAIT TIMEで設定されたタイムアウト時間を超えているRETURN RECEIPTトランザクションおよびRETURN TWOSAFEトランザクションの数を追跡します。タイムアウト数がDISABLE RETURNで設定した最大値を超えると、アプリケーションは、デフォルトのレプリケーション・サイクルに戻り、レプリケート対象の更新に対するサブスクライバからの確認応答を待機しなくなります。
DISABLE RETURN SUBSCRIBERを設定して、タイムアウトしたサブスクライバに対してのみRETURNサービス･ブロッキングを無効にするポリシーを設定するか、またはDISABLE RETURN ALLを設定して、すべてのサブスクライバに対してRETURNサービス･ブロッキングを無効にするポリシーを設定できます。DISABLE RETURN障害ポリシーによって特定のサブスクライバが無効にされているかどうかを確認するには、ttRepSyncSubscriberStatus組込みプロシージャまたはSNMPトラップttRepReturnTransitionTrapを使用します。
DISABLE RETURN障害ポリシーは、レプリケーション・エージェントが稼働している場合にのみ有効になります。この障害ポリシーは、レプリケーション・エージェントを停止し、DISABLE RETURN SUBSCRIBERまたはDISABLE RETURN ALLのいずれかをNumFailures の値を0にして指定すると取り消すことができます。障害ポリシーをトリガーするタイムアウトのカウントは、レプリケーション・エージェントを再起動したとき、DISABLE RETURN値を0に設定したとき、またはRETURNサービス・ブロッキングがRESUME RETURNによって再度有効にされたときにリセットされます。
| 注意: | DISABLE RETURNは、各サブスクライバのタイムアウトの累積カウントを保持します。複数のサブスクライバが存在する場合にDISABLE RETURN SUBSCRIBERを設定すると、レプリケーション・エージェントは、タイムアウトのしきい値に最初に達したサブスクライバのRETURNサービス・ブロッキングを無効にします。その後、他のいずれかのサブスクライバがタイムアウトのしきい値に達すると、レプリケーション・エージェントは、そのサブスクライバのRETURNサービス・ブロッキングを無効にし、以降同様に処理します。 |
masterdsデータ・ストアからsubscriber1およびsubscriber2データ・ストアに更新をレプリケートするように、CREATE REPLICATION文を設定しています。CREATE REPLICATION文では、NumFailuresの値を5にしてRETURN RECEIPTおよびDISABLE RETURN SUBSCRIBERの使用が指定されています。RETURN WAIT TIMEは30秒に設定されています。
CREATE REPLICATION repl.myscheme
ELEMENT e TABLE repl.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1 ON "server2",
subscriber2 ON "server3"
RETURN RECEIPT
STORE masterds ON "server1"
DISABLE RETURN SUBSCRIBER 5
RETURN WAIT TIME 30;
アプリケーションでマスターへの更新をコミットすると、subscriber1で問題が発生し、レプリケート対象のトランザクション更新の確認に失敗します。アプリケーションは、マスターへの次の更新をコミットするまで30秒ブロックされます。アプリケーション・セッションの期間中、このコミット/タイムアウトのサイクルは、DISABLE RETURNによってsubscriber1のRETURN RECEIPTブロッキングが無効になるまでこの後4回繰り返されます。アプリケーションは、subscriber1からではなく、subscriber2からのRETURN RECEIPT確認応答を継続して待機します。
RETURN SERVICES OFF WHEN REPLICATION STOPPEDは、RETURN RECEIPTサービスのデフォルト設定のため、RETURN RECEIPTは次のいずれかの場合に無効になります。
RETURNサービス・ブロッキングが無効であるとは、マスター・データ・ストアのアプリケーションが、レプリケーション更新を受信またはコミットしたサブスクライバからの確認応答を待機している間、実行をブロックしないということです（図1.3および図1.4を参照）。ただし、「デフォルトのレプリケーション」で説明されているデフォルトのレプリケーションの場合と同様に、マスターは、レプリケート対象の更新の各バッチについてサブスクライバからの確認応答をリスニングしていることに注意してください。
RETURNサービス・リカバリ・ポリシーは、RESUME RETURN属性を設定し、再開待機時間の値を指定して設定できます。この属性が設定され、サブスクライバに対するRETURNサービス・ブロッキングが無効になっている場合に、トランザクションのコミット確認応答時間がRESUME RETURNで設定した値より小さくなると、RETURN RECEIPTまたはRETURN TWOSAFEサービスが再開されます。コミット確認応答時間とは、アプリケーションがコミットを実行してから、マスターがサブスクライバから更新の確認応答を受信するまでの待機時間のことです。図1.3のステップ2および5を参照してください。
たとえば、RETURN RECEIPTブロッキングがsubscriber1に対して無効になっている場合にRESUME RETURNを8ミリ秒に設定すると、RETURN RECEIPTブロッキングは、マスターのアプリケーションで更新がコミットされてから8ミリ秒未満でその更新の確認応答を受け取るとすぐにsubscriber1に対して再開されます。
CREATE REPLICATION repl.myscheme
ELEMENT e TABLE repl.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber1 ON "server2",
subscriber2 ON "server3"
RETURN RECEIPT
STORE masterds ON "server1"
DISABLE RETURN SUBSCRIBER 5
RESUME RETURN 8;
RESUME RETURNポリシーは、レプリケーション・エージェントが稼働している場合にのみ有効になります。RETURN RECEIPT再開ポリシーは、レプリケーション・エージェントを停止した後、ALTER REPLICATIONを使用してRESUME RETURNを0（ゼロ）に設定して取り消すことができます。
DURABLE COMMIT属性を設定して、DISABLE RETURNでRETURNサービス・ブロッキングを無効にしたアプリケーションに永続コミット・ポリシーを指定できます。DURABLE COMMITをONに設定すると、マスター・データ・ストアのDurableCommits設定が上書きされ、RETURNサービス・ブロッキングを無効にしたトランザクションに対して永続コミットが強制実行されます。
| 注意: | RETURN SERVICES ON WHEN REPLICATION STOPPEDを指定してレプリケーション・スキームを構成した場合、DURABLE COMMITポリシーが施行されるには、レプリケーション・エージェントが稼働している必要があります。 |
たとえば、DISABLE RETURN ALLポリシーを設定してすべてのサブスクライバのRETURN RECEIPTブロッキングを無効にすると、DURABLE COMMIT ONを設定できます。RETURN RECEIPTブロッキングを無効にすると、コミットが永続的にディスクにコミットされ、冗長性が提供されます。
CREATE REPLICATION repl.myscheme
ELEMENT e TABLE repl.tab
MASTER masterds ON "server1"
SUBSCRIBER subscriber ON "server2",
subscriber2 ON "server3"
RETURN RECEIPT
STORE masterds ON "server1"
DISABLE RETURN ALL 5
DURABLE COMMIT ON
RESUME RETURN 8;
| 注意: | DURABLE COMMITは、サブスクライバが1つのみの場合も有効です。ただし、例3.13および例3.14で示したように、2つのサブスクライバに同じデータをレプリケートし、一方のサブスクライバのRETURNサービス・ブロッキングを無効にした場合は、永続コミットを有効にするより、他方のサブスクライバを使用したほうが、より高いパフォーマンスを得ることができます。 |
